feat: Add AI helpers to Javascript and Queries - #41590

## Description

**TL;DR** — Ask AI (AI-assisted code editing in the JS/query editors,
plus an admin page to configure the AI provider) currently exists only
in the enterprise edition. Nothing about it is actually
enterprise-specific, so this brings it to CE. The code is ported from
`appsmith-ee/release` unchanged where it already lives in `ce` packages,
and moved from `src/ee` into `src/ce` where it does not.

### Background

Ask AI was originally built for CE on `feat/enable-ai` (PR #41590). That
PR was handed over for review in March, went quiet, and was closed by
the stale bot on 2026-04-03 without ever being merged. The feature
instead shipped in the enterprise repo as `appsmith-ee#8845`, and CE
received only inert stubs via #41692 —
`ce/selectors/aiAssistantSelectors.ts` and friends returning `null` /
`false` / `[]`.

That split was not driven by any technical requirement:

- `ee/selectors/aiAssistantSelectors.ts` contains **no license or
entitlement check** — it reads `state.aiAssistant` and nothing else.
- Enablement is ordinary organization configuration
(`AIAssistantConfig.isAIAssistantEnabled`), set by an instance admin.
- The feature flag that once gated it was removed wholesale in
`appsmith-ee#9119`.

The enterprise-only placement was a product decision, and this PR
reverses it.

### Why port from EE rather than revive the original branch

`feat/enable-ai` is four months stale and EE has since reworked the
implementation:

| | `feat/enable-ai` | `appsmith-ee/release` |
|---|---|---|
| AI settings storage | flat fields on `OrganizationConfiguration` |
nested `AIAssistantConfig` document |
| Provider dispatch | inline `if` chain | extracted `dispatchToProvider`
|
| Datasource schema enrichment | client-side | server-side
`AiDatasourceSchemaSerializerCE` |
| `/ai-config` endpoints | ~1450 lines inlined into
`OrganizationControllerCE` | dedicated `AIConfigControllerCE` +
`AIConfigServiceCE` |
| `AIReferenceServiceCEImpl` | 239 lines | 107 lines |

Reviving the branch would land a divergent second implementation and
guarantee a conflict with the community sync. Porting EE's current
version starts CE and EE byte-identical on the `ce`-package files. Note
the security commit and the review fixes on top of it deliberately move
CE **ahead** of EE, so the sync is no longer a no-op — see **CE→EE sync:
required resolution** below for the exact steps.

### Architecture

**Server** — follows the existing `controller → ce service →
ce_compatible → ee override` layering, all in `ce` packages:

- `AIConfigControllerCE` / `AIConfigController` for `/ai-config`
(`test-connection`, `fetch-models`, `test-api-key`), each gated on
`MANAGE_ORGANIZATION`
- `AIConfigServiceCE(Impl)`, `AIAssistantServiceCE(Impl)`,
`AIReferenceServiceCE(Impl)` with their `ee` override points and
`AIConfigServiceCECompatible(Impl)`
- `AIAssistantConfig` on `OrganizationConfiguration`, `Migration075`,
and the `AIProvider` / DTO types
- `POST /users/ai-assistant/request` on `UserControllerCE`
- `ai-references/*.md` prompt-reference resources

**Client** — the implementation moves from `src/ee` into `src/ce`, which
is where a CE-owned feature belongs. This is safe because the EE UI
files import nothing EE-only; every import is a package, a shared path,
or an `ee/` alias that resolves through CE's shims. The existing
`src/ee` shims from #41692 are untouched and now re-export real code
instead of stubs, and the exported symbol surface of every relocated
file is unchanged. The AI reducer and saga are registered in
`ce/reducers` and `ce/sagas` rather than their `ee` counterparts, and
the admin AI settings page is registered for superusers.

**This PR adds no `src/ee` files**, because the CE pre-push architecture
guard rejects them. Four CE-owned modules therefore have no `ee` shim to
import through — `aiAssistantReducer`, `AIAssistantSagas`, `GPT/shared`,
and the admin AI config — so they are imported from `ce/` directly, each
with a documented `eslint-disable` for `no-restricted-imports`. That is
the same accommodation the native Custom Widget copilot uses in #42063.
If EE would rather route these through `ee/` shims, those shims belong
in a companion EE PR.

Adds `react-markdown` and `remark-gfm`, used by the assistant's response
renderer.

### Impact on existing instances

Inert by default. `AIAssistantConfig` is absent until an admin
configures a provider, `isAIAssistantEnabled` defaults to false, and
`Migration075` only adds the field. With nothing configured, the Ask AI
affordances stay hidden exactly as they do today — no feature flag is
involved, matching how EE ships it since #9119.

### Security fixes included

A nine-reviewer council on the ported code surfaced four defects. All
four are inherited byte-identical from EE and are therefore **live in EE
production today**; because EE's `AIConfigServiceImpl` delegates every
method to the CE class and `AIAssistantServiceImpl` overrides nothing,
fixing them here carries them into EE through the sync rather than
needing a parallel EE change.

1. **SSRF, two call sites.** `callLocalLLMAPI` built a raw `WebClient`,
bypassing `WebClientUtils` and substituting a check that tested only
`isLinkLocalAddress` on the first resolved address — missing loopback,
and racy. `callAzureOpenAIAPI` chained `.clientConnector(...)` *after*
`WebClientUtils.builder()`, which replaces the connector carrying the
DNS-aware resolver; it read as protected and was not. Both now build
through `WebClientUtils.builder(httpClient)`.
2. **`getAIConfig` authorization.** It was the only one of five service
methods without `MANAGE_ORGANIZATION`, disclosing `localLlmUrl`,
`azureOpenaiEndpoint` and the deployment name to any authenticated user,
on every session. Managers still get the full configuration; everyone
else gets enablement, provider, and credential-presence booleans —
exactly what the client consumes.
3. **API keys stored in cleartext.** The `@Encrypted` annotations never
applied — the traversal only descends into `AppsmithDomain` types, and
the write is a sparse `updateById` so the encrypting lifecycle listener
never fires. `AIConfigSecretsCE` now encrypts and decrypts at the few
write/read points, and `Migration076` encrypts existing values in place,
idempotently.
4. **Admin key field corrupted credentials.** A stored key loaded into
the input as the literal `••••••••` with a save guard comparing against
that mask, so typing without clearing persisted `••••••••sk-…` behind a
success toast.

**Behaviour change worth calling out:** a local-LLM URL pointing at
loopback is now refused. In the single-container CE deployment
`127.0.0.1` is Mongo, Redis and RTS rather than the operator's Ollama —
which is the reason to refuse it. A local model on another host or
container stays reachable by hostname or private IP. This also makes the
runtime path agree with `/ai-config/test-connection`, which already went
through `WebClientUtils`.

### Follow-ups (tracked, not addressed here)

1. **Unmetered LLM spend** — `/users/ai-assistant/request` has no rate
limit or per-user quota; on an open-signup CE instance any account can
drain the admin's provider billing.
2. **OpenAI provider lacks guards the others have** — no
empty/max-length prompt validation and no `max_tokens`.
3. **`/users/ai-assistant/request` maps every failure to 400**,
including upstream timeouts, which hurts monitoring.
4. **A measured 0.5–1.0 s reactive-thread stall** in
`AiDatasourceSchemaSerializerCE.extractReferencedTableNames` at the
DTO's own size ceilings.
5. **Dead code carried from EE** — `AIWindow` and the in-editor
`AISidePanel` have no importer, and `ce/utils/aiSchemaSerializer.ts` has
no consumer but its own test.
6. **Test coverage** — `AIConfigSecretsCE` and `Migration076` both route
through `EncryptionHelper`, whose static initialiser needs
`APPSMITH_ENCRYPTION_PASSWORD`/`SALT`. Those are set for the
integration-test and Docker CI jobs but not for `server-unit-tests`, so
this coverage belongs in the integration suite.

A follow-up in `appsmith-ee` should reduce EE's `src/ee` Ask AI files to
re-export shims and drop its `ee/reducers` + `ee/sagas` registration, so
EE consumes this CE implementation instead of shadowing it.

https://linear.app/appsmith/issue/APP-15737

Supersedes the original, stale-closed CE attempt in #41590.

## Automation

/ok-to-test tags="@tag.All"

### 🔍 Cypress test results
<!-- This is an auto-generated comment: Cypress test results  -->
> [!TIP]
> 🟢 🟢 🟢 All cypress tests have passed! 🎉 🎉 🎉
> Workflow run:
<https://github.com/appsmithorg/appsmith/actions/runs/30836147916>
> Commit: deab697
> <a
href="https://internal.appsmith.com/app/cypress-dashboard/rundetails-65890b3c81d7400d08fa9ee5?branch=master&workflowId=30836147916&attempt=2"
target="_blank">Cypress dashboard</a>.
> Tags: `@tag.All`
> Spec:
> <hr>Mon, 03 Aug 2026 18:47:45 UTC
<!-- end of auto-generated comment: Cypress test results  -->


## Communication
Should the DevRel and Marketing teams inform users about this change?
- [x] Yes
- [ ] No

Ask AI becoming available in the community edition is a user-facing
change worth announcing.



## CE→EE sync: required resolution

**This section is load-bearing. The sync of this PR is not a no-op, and
two of its failure modes arrive through *clean* merges — no conflict
marker will surface them.** Whoever runs the sync should follow this,
and it is the condition the architecture review set for unblocking.

Of the changed files that also exist in EE, **18 differ from EE's
copy**. Most are the deliberate hardening in the security commit, which
moves CE ahead of EE on purpose. Five are add/add conflicts
(`ce/sagas/AIAssistantSagas.ts`, `ce/pages/AdminSettings/config/ai.tsx`,
`pages/AdminSettings/AI/index.tsx`, `AIAssistantServiceCEImpl.java`,
`AIConfigServiceCEImpl.java`).

> **These steps are for the sync itself. None of them can be pre-landed
in EE as a separate PR — verified against `appsmith-ee/origin/release`
(`0aff44fa56`, "Sync community release"):**
>
> - **The saga.** EE's `ce/sagas/index.tsx` does **not** register the AI
saga yet — only `ee/sagas/index.tsx` does. Removing EE's registration
*before* the CE change syncs would leave zero registrations and take Ask
AI out of EE entirely. It is only safe once CE's registration has
arrived.
> - **The enum.** EE's `ASK_AI_ORG_CONFIG_UPDATED` /
`ASK_AI_ORG_TEST_RUN` are referenced by `AIConfigServiceCEImpl` (lines
172-173, 236) and its test. Deleting them ahead of the sync breaks EE's
compile. This is a conflict *resolution*, not a change that exists
independently.
>
> So this is work for whoever runs the sync, in the same merge — not a
companion PR that can land first.

### 1. Remove EE's now-duplicate saga registration

CE now registers the AI saga itself, and that CE file merges **cleanly**
into EE — so EE ends up registering it twice:

| EE file | What to do |
|---|---|
| `app/client/src/ee/sagas/index.tsx` | **Remove** the
`aiAssistantSagas` import (from `ee/sagas/AIAssistantSagas`, a shim that
re-exports `ce/sagas/AIAssistantSagas`) and its entry in the saga array
— CE's registration now covers EE |

Left as-is, EE runs the *same* watcher generator twice, so every Ask AI
action fires duplicate requests to the provider — double latency and
double spend.

This one genuinely needs an EE change: EE builds `sagasArr` as
`[...CE_Sagas, …, aiAssistantSagas]`, appending its own entry *after*
spreading CE's list, so CE cannot deduplicate it from its side.

**The duplicate admin category no longer needs an EE change.**
`ConfigFactory.register` is CE-owned and was a raw push into three
collections (`categories`, `settings`, `savableCategories` — only
`settingsMap` was keyed and therefore safe). It is now idempotent, so a
category registered from both `ce/` and `ee/` collapses to one entry on
its own. EE's `ConfigFactory.register(AIConfig)` can stay exactly as it
is.

### 2. Resolve the five add/add conflicts toward CE, wholesale

`Migration076EncryptAIAssistantApiKeys` merges cleanly and will encrypt
EE's stored keys on first boot. EE's current `AIAssistantServiceCEImpl`
/ `AIConfigServiceCEImpl` read those keys **without**
`AIConfigSecretsCE.decrypt`. If either file is resolved toward EE's
copy, **EE sends ciphertext as its `Authorization` header and Ask AI
breaks in EE**.

`pages/AdminSettings/AI/index.tsx` must also move together with
`AIConfigServiceCEImpl` — the client's `hasStoredX` model depends on the
server's `has*` response shape and the manager-only full config.

### 3. Collapse the duplicated analytics enum

`AnalyticsEvents.java`: CE adds `ASK_AI_ORG_CONFIG_UPDATED` /
`ASK_AI_ORG_TEST_RUN` at the enum tail (lines 106/109); EE already has
both at lines 140/143. Naive resolution produces duplicate enum
constants and **fails to compile**. Keep one pair.

### Correction to an earlier claim in this description

An earlier revision said porting from EE keeps the two editions
"byte-identical on the `ce`-package files, so the sync stays a no-op".
That was true of the initial port and is **no longer true**: the
security commit, and the review fixes on top of it, deliberately move CE
ahead. The byte-identity argument still holds for the ~40 untouched
ported files and for the reason to port rather than revive
`feat/enable-ai`, but the sync itself needs the three steps above.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
* Added Ask AI assistance for JavaScript, SQL, GraphQL, and JSON
editing.
* Added resizable chat panels with conversation history, editor context,
Markdown responses, quick actions, and keyboard shortcuts.
* Added a global AI assistant panel with context-aware prompts and
schema support.
* Added administrator settings for Claude, OpenAI, Azure OpenAI, and
local Ollama-compatible providers.
* Added connection, credential, and model testing with secure credential
handling and request safeguards.
* **Documentation**
* Added reference guides for JavaScript, SQL, GraphQL, and common
troubleshooting scenarios.
* **Tests**
  * Added coverage for schema handling and AI configuration workflows.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>